Method and system for remote activation and management of personal security devices

ABSTRACT

Managing a Personal Security Device (PSD) includes retrieving proprietary information from a remote storage location using a first Remote Computer System, providing at least one Client as a host to the PSD and establishing a communications pipe over a first network between the PSD and the Remote Computer System. The communications pipe communicates with the PSD through the Client. Managing a PSD also includes transmitting the proprietary information from the Remote Computer System to the PSD by sending a PSD-formatted message through the communications pipe, where the proprietary information provided in the PSD-formatted message and passing through the Client is at least partially inaccessible by the Client, processing the PSD-formatted messages at the PSD to extract the proprietary information and storing the proprietary information in the PSD.

RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.14/091,374, filed Nov. 27, 2013 (pending), which is a continuation ofU.S. application Ser. No. 13/216,727, filed Aug. 24, 2011 (U.S. Pat. No.8,626,947), which is a continuation of U.S. application Ser. No.10/476,329, filed Oct. 29, 2003 (U.S. Pat. No. 8,028,083), which is theNational Stage of International Application No. PCT/EP2002/03930, filedApr. 9, 2002, which is a continuation-in-part of Ser. No. 09/844,246filed Apr. 30, 2001 (abandoned), 09/844,439 filed Apr. 30, 2001(U.S.Pat. No. 7,363,486) and 09/844,272 filed Apr. 30, 2001 (U.S. Pat. No.7,225,465), which are hereby incorporated by reference.

1. FIELD OF INVENTION

The present invention relates to a data processing method and system forremote activation and management of Personal Security Devices (PSD) overa network for purposes of obtaining services or data from one or moreRemote Computer Systems. More particularly, the invention relates to asecure single-step method of activating and managing a Personal SecurityDevice.

2. BACKGROUND OF INVENTION

The current art involving the management of Personal Security Devices(PSD), for example, smart cards, requires a multi-step process where allthe information necessary to use a PSD is loaded into this PSD prior todistribution, including an initial Personal Identification Number orPIN. The PSD is then sent to the end user followed by a separate lettercontaining the initial PIN which the user must enter the first time thePSD is used. Another current alternative affixes an adhesive labelcontaining a telephone number on a PSD prior to issuance. This labelprovides instructions for the end user to telephone a call center toactivate the PSD before the device can be used.

The latter and former methods constitute multi-step processes, whichadds considerably to the initial distribution and subsequent managementcosts of the PSDs. For example, in issuing smart cards, additionalequipment, maintenance, labor and operating costs are required togenerate either the separate mailings containing an initial PIN, or togenerate adhesive labels to be placed on the smart cards and to operatethe call centers which activate the cards.

Another major drawback of the current art concerns the lack of abilityto manage information contained within the PSD after the device isissued. Currently, PSDs, which require changes, are either sent back toa central location or simply discarded and replaced with a new deviceBoth processes are time consuming and costly.

3. SUMMARY OF INVENTION

It is an object of the present invention to provides a post-issuancemethod for securely downloading and managing information inside theprotected domain of a PSD.

This object is achieved with a method for activating and/or managing atleast one PSD with at least a first Remote Computer System over a firstnetwork using at least one Client as a host to said at least one PSD,said method comprising the steps of:

-   -   a) establishing at least one communications pipe over said first        network between said at least one PSD and said at least first        Remote Computer System,    -   b) retrieving proprietary information by said at least first        Remote Computer System from a remote storage location,    -   c) transmitting said proprietary information from said at least        first Remote Computer System to said at least one PSD through        said at least one communications pipe, and    -   d) storing and/or processing said proprietary information in        said at least one PSD.

This improvement over the current art utilizes a communications pipewhich allows downloading of information into a blank PSD andsubsequently managing that information. For purposes of this invention,a blank PSD lacks proprietary algorithms and/or data but does contain anembedded runtime environment and optionally a unique identifier code.

In a first embodiment of the method of the invention, said remotestorage location is in said at least first Remote Computer System.

In a second embodiment of the method of the invention, said remotestorage location is in an at least one subsequent Remote Computer Systemfunctionally connected to said at least first Remote Computer Systemover a second network, and said step b) comprises the step oftransmitting said proprietary information from said at least onesubsequent Remote Computer System to said at least first Remote ComputerSystem through said second network.

These embodiments allow either the Remote Computer System maintainingthe communications pipe (first embodiment) or a subsequent RemoteComputer System (second embodiment) to download proprietary informationsuch as authentication algorithms, cryptographic keys, credentials orcertificates directly into a PSD connected to a local Client through thecommunications pipe without disclosing proprietary information to thelocal Client.

A major advantage of the method of the invention is that it allows blankPSDs to be issued in bulk and activated at a future date without risk ofcompromise. Since no proprietary data is Included in a bulkdistribution, the PSDs are not usable to gain access to secure functionsor data.

An example process by which a blank PSD becomes activated is as follows;an end user, who has previously received a blank PSD, connects the PSDto a local Client and accesses a predetermined site over a networklocated on a Remote Computer System. The Remote Computer System mayoptionally perform end user authentication by some predetermined methodsuch as prompting for a social security number, static PIN, mother'smaiden name, etc. Alternatively, authentication may be implied using aunique identifier contained within the PSD.

Once the end user is properly authenticated or valid PSD connected, aRemote Computer System forms a communications pipe and downloads (firstembodiment), or causes a subsequent Remote Computer System to download(second embodiment), the necessary information through thecommunications pipe and into the PSD. The PSD may become activated uponcompletion of the process or as an additional security measure, the enduser is prompted to devise and enter a unique PIN code to furtherprotect access to the PSD.

In both said embodiments of the invention, a means to manage (e.g.upgrade, change, delete) PSD algorithms and data is facilitated byremotely gaining access to the PSDs and then downloading the changesdirectly into the PSDs, again without leaving proprietary information onthe Clients. Any changes necessary to proprietary information may beperformed entirely within the secure domain of the PSD.

In both said embodiments of the invention, all transactions occur withinthe secure domain of a PSD and a secure remote computer system, thusproviding end-to-end security.

In said second embodiment of the invention, a centralized depository fortracking of PSD changes is provided, which greatly simplifies themanagement of large numbers of PSDs.

It is another object of the invention to provide a system forimplementing the above-mentioned method.

4. BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a generalized system block diagram for implementing a plaincommunications pipe,

FIG. 2 is a detailed block diagram depicting initiating a plaincommunications pipe,

FIG. 3 is a detailed block diagram depicting establishing a plaincommunications pipe,

FIG. 4A is a generalized system block diagram for implementing a securecommunications pipe which includes software-based security mechanisms,

FIG. 4B is a generalized system block diagram for implementing a securecommunications pipe which includes HSM-based security mechanisms,

FIG. 5 is a detailed block diagram depicting initiating a securecommunications pipe,

FIG. 6 is a detailed block diagram depicting establishing a securecommunications pipe,

FIG. 7 is a general system block diagram for implementing theauthentication of a PSD vis-à-vis at least one Remote Computer System,

FIG. 8 is a detailed block diagram illustrating initial authenticationchallenge,

FIG. 9 is a detailed block diagram illustrating initial authenticationresponse,

FIG. 10 is a detailed block diagram illustrating remote authenticationchallenge,

FIG. 11 is a detailed block diagram illustrating remote authenticationresponse,

FIG. 12 is a detailed block diagram illustrating authenticationcredential transfer,

FIG. 13 is a detailed block diagram illustrating remote authenticationchallenge using said transferred credential,

FIG. 14 is a detailed block diagram illustrating remote authenticationresponse using said transferred credential,

FIG. 15A is a general system block diagram for implementing presentinvention using a first Remote Computer System (first embodiment of theinvention),

FIG. 15B is a general system block diagram for implementing presentinvention using a subsequent Remote Computer System (second embodimentof the invention),

FIG. 16 is a detailed block diagram illustrating the direct transfer ofproprietary information to a PSD (first embodiment of the Invention),

FIG. 17 is a detailed block diagram illustrating the remote transfer ofproprietary information to a PSD (second embodiment of the invention).

5. DETAILED DESCRIPTION OF THE INVENTION

In a first part (section 5.1.), the present Detailed Description of theInvention will disclose how to establish a plain communications pipe anda secure communications pipe between a PSD and a Remote Computer System.

In a second part (section 5.2.), the present Detailed Description of theInvention will disclose how to enhance security of an authenticationprocess of a PSD vis-à-vis a Remote Computer System using said securecommunications pipe, and how to use said Remote Computer System as asecure hub for authentication of said PSD vis-à-vis a plurality ofsubsequent Remote Computer Systems.

In a third part (section 5.3.), the present Detailed Description of theInvention will disclose a post-issuance method and system for securelydownloading and managing information inside the protected domain of aPSD.

Said second part of the Detailed Description will be based on the use ofa secure communications pipe, but the present invention is not limitedto such a use.

The use of a plain communications pipe, i.e. of a communications pipewhich does not involve end-to-end cryptographic mechanisms, falls withinthe scope of the present invention.

Note also that the following description of the invention will be basedon a PSD which receives and sends APDU—(Application Protocol DataUnit)—formatted messages.

APDU messaging format, which is per se known in the art, is atower-level messaging format which allows a PSD to communicate withhigher-level applications located in devices to which the PSD is to beconnected.

It must be clear that the present invention is not limited to the use ofan APDU messaging format, and that any other low-level messaging formatthat can be processed by the PSD enters within the scope of the presentinvention.

5.1. Establishment of a Communications Pipe 5.1.1. Plain CommunicationsPipe

Referring to FIG. 1, a generalized system block diagram of thearchitectures of a Client 10 and of a Remote Computer System isdepicted. The various layers shown are based on the Open SystemInterconnection model (OSI). For simplicity, certain layers common toboth the Client and Remote Computer System are not shown and should beassumed to be present and incorporated into adjacent layers. The layerscommon to both a Client and Remote Computer System include:

-   -   an Applications Layer 90 which generally contains higher level        software applications (e.g. word processor) and a user interface        and such as a Graphical User Interface (GUI),    -   an Applications Programming Interface (API) Layer 100 for        processing and manipulating data for use by either higher or        lower level applications,    -   a Communications Layer 105 which contains communications        programs including secure communications capabilities, which        enable a Client to communicate with a Remote Computer System to        exchange information in an agreed upon protocol and visa versa,    -   an Operating System Layer 110 or equivalent runtime environment,        which controls the allocation and usage of hardware resources        such as memory, Central Processing Unit (CPU) time, disk space,        hardware I/O port assignments, peripheral device management,    -   a Hardware Drivers Layer 120 which permits the operating system        to communicate and control physical devices connected to the        Client's or Remote Computer System's hardware I/O bus,    -   and a Physical Device Layer 130 where Network Interface Cards        (NIC) 140 provide the physical connections to a        telecommunications network 45. Other Hardware Devices 60 may        also be connected at this Layer.

5.1.1.1. Client Specific Features

A specialized program contained within the API Layer 100 of the Clientand referred to as a Pipe Client 15, interacts with CommunicationsPrograms contained within the Communications Layer 105. The Pipe Client15 functions to separate encapsulated APDU requests from Incomingmessaging packets received from a network 45 for processing by a locallyconnected PSD 40. Alternately, outbound APDU responses generated by alocally connected PSD 40, are processed by the Pipe Client forencapsulation into an agreed upon communications protocol byCommunications Programs contained within the Communications Layer 105.

A software driver contained within the Communications Layer 105 of theClient and referred to as a PSD Software Interface 20 directs incomingAPDUs communicated by the Pipe Client 15 into the I/O device portconnecting the PSD Hardware Device Interface 25 to the locally connectedPSD 40. Outgoing APDUs generated by the PSD are communicated through thePSD Hardware Device Interface 25 through the I/O device port to the PSDSoftware Interface 20 and subsequently communicated to the Pipe Client15.

5.1.1.2. Remote Computer System Specific Features

A first specialized program contained within the API Layer 100 of theRemote Computer System 50 and referred to as an APDU Interface 55,translates higher level messaging formats into low-level APDU messagingformat required to communicate with a PSD 40. Alternately, the APDUInterface 55 translates incoming APDU responses received from a PSD 40into higher level messaging formats used by programs in the API Layer100 and Applications Layer 90 of the Remote Computer System.

A second specialized program contained within the API Layer 100 of theRemote Computer System 50 and referred to as a Pipe Server 70 interactswith Communications Programs contained within the Communications Layer105. The Pipe Server 70 functions to separate encapsulated APDU requestsfrom incoming messaging packets received from a network 45 forprocessing by the APDU Interface 55. Alternately, outbound APDU requeststranslated by the APDU Interface 55 are processed by the Pipe Server forencapsulation into an agreed upon communications protocol byCommunications Programs contained within the Communications Layer 105.

5.1.1.3. Other Features

The connection 30 between the PSD 40 and PSD Hardware Interface 25includes but is not limited to traditional electrical or optical fiberconnections or wireless means including optical, radio, acoustical,magnetic, or electromechanical. Likewise the connection 75 between theClient 10 and the network 45, and the connection 75 between the RemoteComputer System 50 and the network 45 may be accomplished analogously.

The network, shown generally at 45, includes both public and privatetelecommunications networks connected by traditional electrical,optical, electro-acoustical (DTMF) or by other wireless means. Anymutually agreed upon communications protocol capable of encapsulatingAPDU commands may be employed to establish a plain communications pipeincluding open or secure communications protocols.

Referring now to FIG. 2, depicts initiating a plain communications pipebetween the Remote Computer System 50 and the PSD 40 connected to aClient 10. In this depiction, the Remote Computer System 50 is sending arequest to PSD 40 for non-proprietary embedded information 35, forexample an identification number. PSD 40 is connected 30 to the localClient 10 using PSD Interface 25. PSD Interface 25 communicates with theClient 10 via hardware device port 5.

To initiate a plain communications pipe between Remote Computer System50 and PSD 40, the Remote Computer System 50 generates a request 200 byway of API programs 100 which is translated into APDU format 220 by theAPDU Interface 55 and sent to the Pipe Server 70 for messageencapsulation. The encapsulated APDUs are then sent 210 to theCommunications Programs 105S for incorporation into outgoing messagepackets 230.

The message packets 230 containing the encapsulated APDUs aretransmitted 75 over the network 45 via a Network Interface Card (I/O)130S. The Client 10 receives the message packets 240 containing theencapsulated APDUs which are received from the network 45 via a NetworkInterface Card (110) 130C installed on the local Client. The incomingmessages are processed by Client-side Communications Programs 105C androuted 250 into the Pipe Client 15 for APDU extraction. The extractedAPDUs are sent 260 through hardware device port 5, routed 270 into thePSD Interface 25 and sent to PSD 40 via connection 30 for processingwithin PSD domain 35.

Alternative requests to form a plain communications pipe 75 between aRemote Computer System 50 and a PSD 40 may be initiated by Client 10requesting access to information contained on one or more networkedlocal Clients, by connecting a PSD 40 to PSD Interface 25 whichinitiates a request to form a plain communications pipe 75, or byanother Remote Computer System requesting access to PSD 40.

Referring now to FIG. 3, depicts a PSD response which establishes theplain communications pipe between PSD 40 and Remote Computer System 50.In this depiction, the request previously received is processed withinthe PSD domain 35, which generates a response message. The PSD responseis sent in APDU format from PSD 40 through connection 30 and into PSDinterface 25. The PSD response is then routed 370 through hardwaredevice port 5 and sent 360 to the Pipe Client 15 for processing andencapsulation. The resulting message packets are then sent 350 to theClient-side Communications Programs 105C for incorporation into outgoingmessage packets 340.

The message packets 340 containing the encapsulated APDUs aretransmitted 75 over the network 45 via the Network Interface Card (I/O)130C.

The Remote Computer System 50 receives the message packets 330containing the encapsulated APDUs, which are received from the network45 via the Network Interface Card (I/O) 130S installed on the RemoteComputer System. The incoming messages are processed by server-sideCommunications Programs 105S and routed 310 into the Pipe Server 70 forAPDU extraction. The extracted APDUs are sent 320 to the APDU Interface55 for processing and translation into a higher-level format and sent300 to API Level programs 100 for processing and further transactionswith the PSD 40 if desired.

5.1.2. Secure Communications Pipe

Referring now to FIG. 4A, a generalized system block diagram of oneimplementation of a secure communications pipe is shown. The generalsystem block diagram includes an additional software-based CryptographyModule 470 installed on the Remote Computer System, which is not shownin FIG. 1.

FIG. 4B depicts an alternative to using software-based securitymechanisms. In this alternative, a Hardware Security Module (HSM) 440 isemployed to perform cryptographic functions. To access the HSM, asoftware driver referred to as an HSM S/W Interface 475, is included inthe API Layer 100. The HSM software driver communicates with a physicaldevice interface included in the Physical Device Layer 130. The physicaldevice interface is installed on the I/O bus of the Remote ComputerSystem, and is referred to as an HSM H/W Interface 485. The HSM module440 is connected 430 to the HSM H/W Interface in a manner analogous tothe PSD connection to the PSD Interface previously described. The use ofHSM technologies provides end-to-end security, which further reduces thepossibility of unauthorized disclosure of cryptographic or sensitiveinformation.

Both APDU messaging security mechanisms shown in FIGS. 4A & 4B are usedto generate cryptographic keys necessary to unlock secure functions anddata contained within the secure domain of a PSD, encrypt outgoing APDUsand decrypt incoming encrypted APDUs. The security mechanisms employedin generating a secure pipe may include synchronous, asynchronous or anycombination of cryptography methods.

Secure communications protocols used to communicate over a network areaccomplished by the Communications Programs contained within theCommunications Layers 105. Cryptography used in generating securecommunications may employ the security mechanisms described for APDUmessaging, employ separate mechanisms or employ any combination thereof.

Referring now to FIG. 5, depicts the initiating of a secure pipe betweenthe Remote Computer System and the PSD 40 connected to Client 10. Inthis depiction, Remote Computer System 50 is sending a secure request toPSD 40 for proprietary embedded information 35, for example anauthentication password, PSD 40 is connected 30 to the local Client 10using PSD Interface 25. PSD Interface 25 communicates with the Client 10via hardware device port 5.

To initiate a secure communications pipe between Remote Computer System50 and PSD 40, a request 500 is generated on Remote Computer System 50to access PSD 40 by way of API programs 100 which are translated intoAPDU format by the APDU Interface 55. The APDUs are then sent 520 to aSecurity Module 525 for encryption using a pre-established cryptographymethod. The proper cryptographic parameters may be determined by using alook-up table or database, which cross-references the PSD's uniqueinternal identification information with one or more codes necessary toimplement the appointed cryptography method.

The encrypted APDUs are then routed 510 to the Pipe Server 70 formessage encapsulation. The encapsulated APDUs are then sent 530 to theCommunications Programs 105 for processing, encryption using apre-established secure communications protocol and incorporation intooutgoing message packets 535. The secure message packets 535 containingthe encrypted and encapsulated APDUs are transmitted 75 over the network45 via a Network Interface Card (I/O) 130S.

The Client 10 receives the message packets 540 containing the encryptedand encapsulated APDUs which are received from the network 45 via aNetwork Interface Card (I/O) 130C installed on the local Client 10.

The incoming encrypted message packets are decrypted and processed usingthe pre-established cryptography employed in the secure communicationsprotocol by Client-side Communications Programs 105C. The unencryptedmessage packets still containing the encrypted APDUs are routed 550 intothe Pipe Client 15 for APDU extraction. The extracted APDUs are sent 560through hardware device port 5, routed 570 into the PSD Interface 25 andsent to PSD 40 via connection 30 for decryption and processing withinthe secure domain 35 of the PSD 40. Using a pre-established cryptographymethod. incoming secure APDUs are decrypted and requests processed.

Referring now to FIG. 6, depicts a PSD secure response, whichestablishes the secure communications pipe between PSD 40 and RemoteComputer System 50. In this depiction, the secure request previouslyreceived is processed within the secure domain 35 of the PSD 40, whichcauses the PSD to generate a secure response message using apre-established cryptography method.

The PSD secure response is sent in APDU format from PSD 40 throughconnection 30 and into PSD interface 25. The PSD secure response is thenrouted 670 through hardware device port 5 and sent 660 to the PipeClient 15 for processing and encapsulation. The resulting messagepackets are then sent 650 to the Client-side Communications Programs 105for processing, encryption using a pre-established secure communicationsprotocol and incorporation into outgoing message packets 640. Themessage packets 640 containing the encapsulated APDUs are transmitted 75over the network 45 via the Network Interface Card (110) 130C.

The Remote Computer System 50 receives the message packets 635containing the encapsulated APDUs from the network 45 via the NetworkInterface Card (I/O) 130S installed on the Remote Computer System 50.The incoming messages are processed and decrypted using thepre-established cryptography method employed in the securecommunications protocol by the server-side Communications Programs 105and routed 610 into the Pipe Server 70 for secure APDU extraction. Theextracted secure APDUs are sent 630 to the Security Module 525 fordecryption of the secure APDUs using the pre-established cryptographymethod. The decrypted APDUs are then routed 620 to the APDU Interface 55for processing and translation into a higher-level format and sent 600to API programs 100 for processing and further transactions with the PSD40 if desired. This step establishes the secure “pipe” to communicatewith the PSD. The secure pipe is maintained until the Remote ComputerSystem signals the Client to close the hardware interface port 5.

No limitation is intended in the number of PSDs and Clients formingcommunications pipes 75 with one or more Remote Computer System(s) 50,nor should any limitation on the number of Remote Computer Systems 50available for generating communications pipes 75 be construed from thedrawings. Lastly, no limitation is intended concerning the initiatingevent to establish a communications pipe.

5.2. Authentication Method Using a Communications Pipe

As already mentioned above, description of said authentication methodwill be based on the use of a secure communications pipe, but thepresent invention is not limited to such a use.

The use of a plain communications pipe falls within the scope of thepresent invention.

The steps involved in performing authentication through a securecommunications pipe are shown in FIGS. 7 through 14. FIG. 7 is ageneralized system block diagram. FIGS. 8 through 11 illustrate a firstvariant where responses to authentication challenges are generatedwithin the secure domain of a Personal Security Device. FIGS. 12 through14 illustrate a second variant where a Remote Computer System acting asa secure hub provides the proper response to authentication challenges,rather than directing challenges through the communications pipe intothe PSD for processing. Characters shown with a prime sign (e.g. C′)indicate a duplicate of an original authentication credential. Otherdrawing details shown but not described refer to information describedin previous section 5.1.

Referring now to FIG. 7, a generalized system block diagram is depicted,where a Personal Security Device 1040 is connected to a Client 1010which is itself connected over a network 1045 to a Remote ComputerSystem 1050 using a secure communications pipe 1075 as described inprevious section 5.1.2. Remote Computer System 1050 is operating as asecure hub following initial authentication as described below, toservice authentication requests made by subsequent Remote ComputerSystems sent over a network 1045 or 1045A.

The subsequent Remote Computer System 1150 is an example of a systemrequiring authentication when a request for secure functions or data issent from Client computer 1010 over the networks 1045 and 1045A. Thesecure communications pipe 1075 applies to authentication transactionsbut does not restrict nor control non-secure transactions occurring overeither network 1045 or 1045A.

Networks 1045 and 1045A may be a common network as in a virtual privatenetworking arrangement or separate networks such as private intranet andpublic internet arrangements. The networks 1045 and 1045A are depictedseparately for illustrative purposes only. No limitation is intended inthe number of PSDs and Clients forming communications pipes 1075 withone or more secure hubs 1050; nor should any limitation on the number ofsubsequent Remote Computer Systems 1150 available for authentication beconstrued from the drawing. Transactions not involving authenticationsare not restricted to the secure hub.

The basic operation of the secure hub may be initiated when an end userat a Client requests access to secure functions or data contained on oneor more Remote Computer Systems connected by a network. An availableRemote Computer System, in which a secure communications pipe has beenestablished as described in previous section 5.1.2., authenticates theend user and Client using the security mechanisms contained within thesecure domain of the PSD. Alternatively, an external event such as aneed to update information within a PSD may trigger a subsequent RemoteComputer System to initiate the authentication process.

Once an initial Client authentication has been accomplished by theavailable Remote Computer System, subsequent authentication challengestransmitted over a network 1045 or 1045A made by subsequent RemoteComputer Systems are directed to the Remote Computer System 1050 actingas a secure hub and depending on which variant employed, are eitherrouted through the appropriate communications pipe 1075 to PSD 1040 orare directly authenticated by the Remote Computer System 1050.

5.2.1. First Variant of Authentication Method

Referring to FIG. 8, to establish a secure hub, a Client 1010 causes anauthentication challenge to be generated on a Remote Computer System1050, by requesting access to secure functions or data over a network1045. Upon receiving the request from Client 1010, the Remote ComputerSystem 1050 generates an authentication challenge 1205 within a securedomain designated as authentication routine 1065. The authenticationchallenge is processed by an API level program 1100 and routed 1200 toan APDU interface 1055 for translation into an APDU format. The APDUsare then sent 1220 to a Security Module 1225 for encryption. Theencrypted APDUs are then routed 1230 to a Pipe Server 1070 forencapsulation into outgoing messaging and sent 1210 to theCommunications Programs 1105S for transmission over the communicationspipe 1075, through the network 1045 into the network interface 1130C ofthe Client 10. The incoming messages are then routed 1240 toCommunications Programs 1105C for processing.

Following processing, the messages are sent 1250 to a Pipe Client 1015for separation of the encapsulated APDUs. The APDUs are their sent 1260through a hardware device port 1005 assigned to a PSD Interface 1025.PSD Interface 1025 routes the incoming APDUs into the PSD 1040 viaconnection 1030, where it is subsequently decrypted and processed withinits secure domain 1035.

Referring to FIG. 9. once PSD 1040 has processed the authenticationchallenge within the secure domain 1035 of the PSD, an authenticationresponse message is generated using a pre-established cryptographymethod.

The authentication response is sent in APDU format from PSD 1040 throughconnection 1030 and into PSD Interface 1025. The PSD secure response isthen routed 1370 through hardware device port 1005 and sent 1360 to thePipe Client 1015 for processing and encapsulation. The resulting messagepackets are then sent 1350 to the

Client-side Communications Programs 1105C for processing, encryptionusing a pre-established secure communications protocol and incorporationinto outgoing message packets 1340. The message packets 1340 containingthe encapsulated APDUs are transmitted 1075 over the network 1045 via anetwork interface card (I/O) 1130C.

The Remote Computer System 1050 receives the message packets 1335containing the encapsulated APDUs from the network 1045 via a networkinterface card (I/O) 1130S installed on the Remote Computer System. Theincoming messages are processed and decrypted using the pre-establishedcryptography method employed in the secure communications protocol bythe server-side Communications Programs 1105S and routed 1310 into thePipe Server 1070 for secure APDU extraction. The extracted secure APDUsare sent 1330 to the Security Module 1325 for decryption of the secureAPDUs using the pre-established cryptography method. The decrypted APDUsare then routed to the APDU Interface 1055 for processing andtranslation into a higher-level format and sent 1300 to API Levelprograms 1100 for processing. If authentication is successful, theRemote Computer System 1050 allows access to secure functions or dataand establishes itself as a secure hub. If authentication fails, the enduser will be unable to access secure functions or data.

Referring to FIG. 10, once the secure hub has been established aspreviously described, remote authentication of subsequent RemoteComputer Systems may be accomplished. Remote authentication may beinitiated either by a Client's request for access to secure functions ordata or by other Remote Computer Systems to perform transactions withinthe secure domain of a PSD.

To perform a remote authentication, a challenge 1085 is issued by asubsequent Remote Computer System 1150. The challenge is routed over anetwork 1045, into the secure hub 1050. The incoming challenge isprocessed and decrypted in the secure hub 1050 using the pre-establishedcryptography method employed in the secure communications protocol bythe server-side Communications Programs 1105S and routed 1085 to an APIlevel program 1100 where it is processed and routed 1400 to an APDUinterface 1055 for translation into an APDU format. The APDUs are thensent 1420 to a Security Module 1425 for encryption. The encrypted APDUsare then routed 1430 to a Pipe Server 1070 for encapsulation Intooutgoing messaging and sent 1410 to the communications programs 1105Sfor transmission over the communications pipe 1075, through the network1045 into the network interface 1130C of the Client 1010.

The incoming messages are then routed 1440 to Communications Programs11050 for processing. Following processing, the messages are sent 1450to a Pipe Client 1015 for separation of the encapsulated APDUs. TheAPDUs are then sent 1460 through a hardware device port 1005 assigned toa PSD Interface 1025. PSD Interface 1025 routes the incoming APDUs intothe PSD 1040 via connection 1030, where it is subsequently decrypted andprocessed within its secure domain 1035.

Referring to FIG. 11, once PSD 1040 has processed the authenticationchallenge within its secure domain 1035, an authentication responsemessage is generated using a pre-established cryptography method. Theauthentication response is sent in APDU format from PSD 1040 throughconnection 1030 and into PSD interface 1025. The PSD secure response isthen routed 1570 through hardware device port 1005 and sent 1560 to thePipe Client 1015 for processing and encapsulation. The resulting messagepackets are then sent 1550 to the Client-side Communications Programs11050 for processing, encryption using a pre-established securecommunications protocol and incorporation into outgoing message packets1540. The message packets 1540 containing the encapsulated APDUs aretransmitted 1075 over the network 1045 via network interface card (I/O)1130C.

The secure hub 1050 receives the message packets 1535 containing theencapsulated APDUs from the network 1045 via network interface card(I/O) 1130S. The incoming messages are processed and decrypted using thepre-established cryptography method employed in the securecommunications protocol by the server-side Communications Programs 1105Sand routed 1510 into the Pipe Server 1070 for secure APDU extraction.The extracted secure APDUs are sent 1530 to the Security Module 1525 fordecryption of the secure APDUs using the pre-established cryptographymethod. The decrypted APDUs are then routed 1520 to the APDU Interface1055 for processing and translation into a higher-level format and sent1500 to API Level programs 1100 for processing. Authentication Module1065 within the secure hub 1050 remains inactive during the transfer ofauthentication information. The authentication response message is thenrouted 1085 into the Communications Programs 1105S where the response issent over the network 1045 in a pre-established secure communicationsprotocol to the challenging subsequent Remote Computer System 1150.

The incoming response message is decrypted and sent to an AuthenticationModule 1095. If authentication is successful, the subsequent RemoteComputer System 1150 allows access to secure functions or data. Ifauthentication fails, the end user will be unable to access securefunctions or data.

5.2.2. Second Variant of Authentication Method

Referring to FIG. 12 depicts a second variant of the authenticationmethod where the Remote Computer System 1050 transfers copies of the PSDcredentials C 1035, if not pre-existing on said Remote computer System1050. To perform credential transfer, an initial authenticationtransaction is performed by the Remote Computer System 1050 aspreviously described. Following authentication, additional commands aresent by the Remote Computer System 1050 to transfer the specifiedcredentials.

The credentials are generated using a pre-established cryptographymethod and sent in APDU format from PSD 1040 through connection 1030 andinto PSD interface 1025. The PSD secure response is then routed 1670through hardware device port 1005 and sent 1660 to the Pipe Client 1015for processing and encapsulation. The resulting message packets are thensent 1650 to the Client-side Communications Programs 1105C forprocessing, encryption using a pre-established secure communicationsprotocol and incorporation into outgoing message packets 1640. Themessage packets 640 containing the encapsulated APDUs are transmitted1075 over the network 1045 via a network interface card (I/O) 1130C.

The Remote Computer System 1050 receives the message packets 1635containing the encapsulated APDUs from the network 1045 via networkinterface card (I/O) 1130S installed on the Remote Computer System.

The incoming messages are processed and decrypted using thepre-established cryptography method employed in the securecommunications protocol by the server-side Communications Programs 1105Sand routed 1610 into the Pipe Server 1070 for secure APDU extraction.The extracted secure APDUs are sent 1630 to the Security Module 1625 fordecryption of the secure APDUs using the pre-established cryptographymethod.

The decrypted APDUs are then routed 1620 to the APDU Interface 1055 forprocessing and translation into a higher-level format and sent 1600 toAPI Level programs 1100 for processing and subsequently sent 1605 to theAuthentication Module 1065 for secure storage and future use. Thetransferred authentication information is shown in FIG. 12 as C′.

In FIG. 13, an authentication challenge 1085 is sent by a subsequentRemote Computer System 1150 over a network 1045. The Remote ComputerSystem 1050 acting as a secure hub receives the incoming challenge 1085from the network 1045 via network interface card 1130S installed on theRemote Computer System 1050. The incoming challenges 1085 are processedand decrypted using the pre-established cryptography method employed inthe secure communications protocol by the server-side CommunicationsPrograms 1105S and routed to API Level programs 1100 for processing. Theprocessed challenge is then sent 1705 to the Authentication Module 1065for authentication using the PSD's transferred credentials C′ 1035′. Thecommunications pipe 1075 may remain intact during this process to allowfor other transactions to occur.

Referring to FIG. 14, the secure hub 1050 generates an authenticationreply within the Authentication Module 1065 which is sent 1805 to theAPI Level Programs 1100 for processing, and subsequently routed 1810 tothe Server-side Communications Programs 1105S for processing, encryptionusing a pre-established secure communications protocol and incorporationinto outgoing message packets. The message packets are routed over thenetwork 1045 to the challenging subsequent Remote Computer System 1150.The incoming messages are then decrypted and the authentication replyprocessed by an internal authentication module 1095. If authenticationis successful, the subsequent Remote Computer System 1150 allows accessto secure functions or data. If authentication fails, the end user willbe unable to access secure functions or data.

5.3. Method and System for Remote Activation and Management of PSDs

The need for secure network communications is paramount for sensitivebusiness and government transactions. The present invention provides animprovement over the current art by allowing issuance of generic PSDs,which can be activated and customized at a later date.

The steps involved in activating a PSD and performing subsequentinformation management through a communications pipe are shown in FIG.15 through 17. For purposes of demonstration, it should be assumed thatany local authentications between the end user, Client and local networkdomain have already been accomplished. Preferentially, a securecommunications protocol is employed over the network between the clientand one or more Remote Computer Systems. It is understood to one skilledin the art. that either embodiment of the invention will work with orwithout the use of secure communications protocols.

Referring now to FIG. 15A, a first embodiment of the invention isdepicted where a Client 2010 and a connected PSD 2040 are connected overa network 2045 with a Remote Computer System 2050 using a communicationspipe 2075 as described in previous section 5.1. The Remote ComputerSystem 2050 maintains the communications pipe 2075 and is available totransfer proprietary information “I” 2165 through the communicationspipe 2075 and into the PSD 2040.

In FIG. 15B, a second embodiment of the invention is depicted where afirst Remote Computer System 2050 acting as a secure hub as described inprevious section 5.2. provides a mechanism for a subsequent RemoteComputer System 2150 connected 2085 to a network 2045 to transferproprietary information “I” 2165′ into a PSD 2040. In this secondembodiment of the invention, proprietary information 2165′ is receivedand processed by a first Remote Computer System 2050. The proprietaryinformation 2165′ is then sent by the first Remote Computer System 2050,through the communications pipe 2075 and into the PSD 2040.

The network 2045 may be a common network as in a virtual privatenetworking arrangement or separate networks such as private intranet andpublic internet arrangements. No limitation is intended in the number ofPSDs 2040 and clients 2010 forming communications pipes 2075 with one ormore Remote Computer Systems 2050, 2150; nor should any limitation onthe number of Remote Computer Systems 2050, 2150 available fortransferring proprietary information 2165, 2165′ be construed from anyof the depictions shown herein.

End user authentication is optional for activating blank PSDs or fordeactivating PSDs already in use. In instances where access to apreviously personalized PSD is desired, authentication transactions maybe required as described in previous section 5.2. to facilitate secureaccess to the PSD. Once the authentication process has beenaccomplished, changes to proprietary information contained within thesecure domain of the PSD are accomplished using the equivalentmethodology described for blank card activation.

Proprietary information 2165, 2165′ for injection into a PSD mayoriginate on a Remote Computer system 2050 supporting a communicationspipe (first embodiment of the invention), on subsequent Remote ComputerSystems 2150 (second embodiment of the invention), or on any combinationof Remote Computer Systems.

Referring to FIG. 16, this drawing illustrates the transfer ofproprietary information from a storage location over a network into aPSD using the Remote Computer System supporting the communications pipe(first embodiment of the invention). This drawing is applicable foreither activating a blank PSD or changing information in an active PSDsubsequent to authentication. In this first embodiment of the invention,the proprietary information 2165 Is called from its storage location2160 within the Remote Computer System 2050.

After retrieval, the proprietary information 2165 is sent 2206 forprocessing into APDU format and encapsulation into the propercommunications messaging format 2204 as described in previous section5.1. After processing, the communications message 2204 is sent throughthe network interface 2130S, into the communications pipe 2075 overnetwork 2045 and received by the client 2010 via a complementary networkinterface 2130C.

The incoming communications messages are sent 2212 for processing wherethe APDU formatted information is separated as described in previoussection 5.1. The separated APDUs are then routed 2216 through thehardware device port 2005 and into 2218 the PSD device interface 2025.The incoming APDUs are then routed 2030 into the secure domain 2035 ofthe PSD 2040 where the information is processed and stored by at leastone embedded algorithm.

For newly issued PSDs lacking proprietary information, the embeddedalgorithm is installed by the PSD issuer and functions to manage theinitial installation of proprietary information. For PSDs alreadycontaining proprietary information, the algorithm may be the same or adifferent algorithm, which may include cryptographic capabilities.

Referring to FIG. 17, this drawing illustrates the transfer ofproprietary information from a remote storage location 1160′ over anetwork 2045 and injection into a PSD 2040 using a plurality of remotecomputer systems 2050, 2150. This second embodiment of the inventioninvolves retrieving proprietary information 2165′ from one or more 2150remote computer systems, sending 2085 the proprietary information over anetwork 2045 where the proprietary information is received and processedby a first Remote Computer System 2050 which is supporting acommunications pipe 2075 and injected into the secure domain 2035 of thePSD 2040.

This second embodiment of the invention is applicable for eitheractivating a blank PSD or changing information in an active PSDsubsequent to authentication. In instances where authentication isrequired, the Remote Computer System supporting the communications pipemay operate as a secure hub as described in previous section 5.2.

In this second embodiment of the invention, the proprietary information2160′ is called from a storage location inside a subsequent RemoteComputer System 2150 or another Remote Computer System, which is localto, and communicating with, the subsequent Remote Computer System 2150.The proprietary information 2165′ is retrieved and sent 2085 over thenetwork 2045 to the Remote Computer System 2050 supporting thecommunications pipe 2075 with the designated PSD 2040.

Remote Computer System 2050 receives the proprietary information throughthe network interface 2130 and routes the incoming proprietaryInformation 2165′ for processing it 2302 into APDU format andencapsulation into the proper communications messaging format 2304 asdescribed in previous section 5.1. After processing, the message 2304 issent through the network interface 2130S, into the communications pipe2075 over network 2045 and received by the client 2010 via acomplementary network interface 2130C.

The incoming communications messages are sent 2312 for processing in2314 where the APDU formatted information is separated as described inprevious section 5.1. The separated APDUs are then routed 2316 throughthe hardware device port 2005 and into 2318 the PSD interface 2025. Theincoming APDUs are then routed 2030 into the secure domain 2035 of thePSD 2040 where the information is processed and stored by at least oneembedded algorithm.

As previously described, for newly issued PSDs lacking proprietaryinformation, the embedded algorithm is installed by the PSD issuer andfunctions to manage the initial installation of proprietary information.For PSDs already containing proprietary information, the algorithm maybe the same or a different algorithm, which may include cryptographiccapabilities.

The foregoing described embodiments of the invention are provided asillustrations and descriptions. They are not intended to limit theinvention to precise form described. In particular, it is contemplatedthat functional implementation of the invention described herein may beimplemented equivalently in hardware, software, firmware, and/or otheravailable functional components or building blocks. Other variations andembodiments are possible in light of above teachings, and it is notintended that the scope of the invention be limited by this DetailedDescription, but rather by the Claims following herein.

What is claimed is:
 1. A method for activating and/or managing at leastone personal security device with at least a first remote computersystem over a first network using at least one client as a host to theat least one personal security device, the method comprising:establishing at least one communications pipe over the first network andthrough the client between the at least one personal security device andthe at least first remote computer system by initially sending a requestto the at least one personal security device for information and the atleast one personal security device providing the requested informationto the remote computer system; retrieving proprietary information by theat least first remote computer system from a remote storage location;transmitting the proprietary information from the at least first remotecomputer system to the at least one personal security device through theat least one communications pipe; and storing and/or processing theproprietary information in the at least one personal security device. 2.The method according to claim 1, wherein the proprietary information isencapsulated to form the personal security device-formatted messages. 3.The method according to claim 1, further comprising: encrypting theproprietary information in the first remote computer system afterretrieving the proprietary information and before transmitting theproprietary information; and decrypting the proprietary information inthe at least one personal security device processing the proprietaryinformation.
 4. The method according to claim 1, wherein the remotestorage location is in the at least first remote computer system.
 5. Themethod according to claim 1, wherein the remote storage location is in asecond remote computer system functionally connected to the first remotecomputer system over a second network and wherein retrieving proprietaryinformation includes transmitting proprietary information from thesecond remote computer system to the first remote computer systemthrough the second network.
 6. The method according to claim 5, furthercomprising: encrypting the proprietary information in the second remotecomputer system; and decrypting the proprietary information in the firstremote computer system.
 7. The method according to claim 1, furthercomprising: authenticating the personal security device through thecommunications pipe.
 8. The method according to claim 1, wherein thecommunications pipe is initiated by the first remote computer system. 9.The method according to claim 1, wherein the communications pipe isinitiated by a second remote computer system requesting access to thepersonal security device.
 10. The method according to claim 1, whereinthe proprietary information is not disclosed to the client.